Skip to content

Remove PDF files after generation #16401

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

rogyar
Copy link
Contributor

@rogyar rogyar commented Jun 26, 2018

Description

Upon invoice/packingslip/credit memo printing the system generates a PDF file directly in the var directory. I see no reason for keeping these files since they are not accessible publicly via web (sharing purpose). There's no "reuse" purpose as well since on every print action a new file with a new filename is being generated.
This PR provides a logic for removing a PDF file once it's generated.
Currently, it's implemented only within a scope of the invoice printing. Once we agree on the solution, I will adjust other places with PDF generation.

Fixed Issues (if relevant)

  1. Print pdf don't delete file in var folder #3535
  2. PDF invoices in /var folder #14517

Manual testing scenarios

  • Open an existing invoice in the admin panel.
  • Click the "Print" button.
  • You should have the invoice downloaded.
  • You should not have a generated PDF file in the var directory.

@magento-engcom-team magento-engcom-team added Partner: Atwix Pull Request is created by partner Atwix partners-contribution Pull Request is created by Magento Partner labels Jun 26, 2018
@magento-engcom-team
Copy link
Contributor

Hi @rogyar. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

  • @magento-engcom-team give me test instance - deploy test instance based on PR changes
  • @magento-engcom-team give me {$VERSION} instance - deploy vanilla Magento instance

For more details, please, review the Magento Contributor Assistant documentation

*/
private function getFileContent($content)
{
if (isset($content['type']) && $content['type'] == 'string') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should check if $content is an array before checking the isset. Not sure that PHP will not complain about this.
In this case is not strictly required, but I suggest always to use the === strict comparison.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isset wont generate a notice in that case if the index does not exist. Also, it's applicable not only to arrays, the function checks that the variable is set. So, not sure we should use is_array here, which may be more expensive and redundant.
As for the strict comparison, absolutely makes sense, thank you.

@phoenix128 phoenix128 self-assigned this Jun 26, 2018
->setHeader('Content-Length', $contentLength === null ? strlen($content) : $contentLength, true)
->setHeader(
'Content-Length',
$contentLength === null ? strlen($this->getFileContent($content)) : $contentLength,
Copy link
Contributor

@phoenix128 phoenix128 Jun 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on code readability:
Since you use getFileContent twice (line 81 and 95), why not to put the result in a variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, the mentioned approach improves the readability, thanks.

* @param string|array $content
* @return string
*/
private function getFileContent($content)
Copy link
Contributor

@ishakhsuvarov ishakhsuvarov Jun 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use type hints in method signatures both for parameters and return types. Looks like only return type applies to this specific case

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I always go this way for a new classes. I had doubts about methods within a scope of existing classes with no type hints/strict types.

Copy link
Contributor

@phoenix128 phoenix128 Jun 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rogyar , you are right if it was public because of possible plugins on it not matching the signature, but with a private method is definitely safe.

Copy link
Contributor

@ishakhsuvarov ishakhsuvarov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great to accompany this PR with a test, preferably integration one

@rogyar
Copy link
Contributor Author

rogyar commented Jun 27, 2018

@ishakhsuvarov absolutely. I'm going to do that as well as adjust packingslips/credit memo generation. Just wanted to make sure that we go the right way. Thank you.

@phoenix128
Copy link
Contributor

LGTM, just check tests.

@rogyar
Copy link
Contributor Author

rogyar commented Jul 6, 2018

Finally, handled the failing tests :)

@magento-engcom-team magento-engcom-team added this to the Release: 2.2.6 milestone Jul 9, 2018
@magento-engcom-team
Copy link
Contributor

Hi @phoenix128, thank you for the review.
ENGCOM-2240 has been created to process this Pull Request

@magento-engcom-team
Copy link
Contributor

Hi @rogyar. Thank you for your contribution.
We will aim to release these changes as part of 2.2.6.
Please check the release notes for final confirmation.

Please, consider to port this solution to 2.3 release line.
You may use Porting tool to port commits automatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants